feat: using websockets events for transaction polling#7822
feat: using websockets events for transaction polling#7822
Conversation
jpuri
force-pushed
the
transaction_polling_improvements
branch
from
70ae62d to
41a0567
Compare
jpuri
force-pushed
the
transaction_polling_improvements
branch
from
e9cf4eb to
45493b2
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
packages/transaction-controller/src/helpers/TransactionPoller.ts
Outdated
Show resolved
Hide resolved
packages/transaction-controller/src/helpers/TransactionPoller.ts
Outdated
Show resolved
Hide resolved
| return; | ||
| } | ||
|
|
||
| if (transaction.status !== 'confirmed') { |
There was a problem hiding this comment.
Do we also want to continue if failed so we can check the receipt and update the status to failed?
There was a problem hiding this comment.
Good point, let me add that.
There was a problem hiding this comment.
PR is updated to check for both dropped and failed statuses also.
There was a problem hiding this comment.
Afraid I can't see this one?
There was a problem hiding this comment.
Oh something I missed with opencode, let me check.
packages/transaction-controller/src/helpers/TransactionPoller.ts
Outdated
Show resolved
Hide resolved
packages/transaction-controller/src/helpers/TransactionPoller.ts
Outdated
Show resolved
Hide resolved
| return; | ||
| } | ||
|
|
||
| if (transaction.status !== 'confirmed') { |
There was a problem hiding this comment.
Should we also check the from of the transaction to confirm it's an outgoing transaction?
There was a problem hiding this comment.
I reverted this change as it is failing for some transactions.
There was a problem hiding this comment.
Can we isolate why? I worry if we got lots of incoming transactions, or spam ones, it might cause excessive requests?
There was a problem hiding this comment.
In case of smart transactions or when from / to is not same as what is submitted.
Subscription will be done only if there are pending requests for that chain thus the probability of an incoming transaction causing a request is low.
But I agree there should be some way to map this update to a pending transaction to confirm that it is not incoming, let me check this more.
There was a problem hiding this comment.
I found that in data returned by transaction updated event the transaction id is same as transaction hash, this can be used to find pending transaction and use its from address:
There was a problem hiding this comment.
I have added check to see if that transaction update received is for one of pending transactions
packages/transaction-controller/src/helpers/TransactionPoller.ts
Outdated
Show resolved
Hide resolved
…/MetaMask/core into transaction_polling_improvements
…ion_polling_improvements
| enum IntervalTrigger { | ||
| Accelerated = 'Accelerated', | ||
| BlockTracker = 'BlockTracker', | ||
| TransactionUpdate = 'TransactionUpdate', |
| return; | ||
| } | ||
|
|
||
| if (transaction.status !== 'confirmed') { |
There was a problem hiding this comment.
Afraid I can't see this one?
| return; | ||
| } | ||
|
|
||
| if (transaction.status !== 'confirmed') { |
There was a problem hiding this comment.
Can we isolate why? I worry if we got lots of incoming transactions, or spam ones, it might cause excessive requests?
2 participants
Explanation
Using event AccountActivityService:transactionUpdated to improve transaction polling.
References
Fixes https://github.com/MetaMask/MetaMask-planning/issues/6948
Checklist
Note
Medium Risk
Changes core transaction polling behavior by introducing a new event-driven trigger and additional filtering logic (chain/account/hash/status), which could affect how quickly transactions update or how often polling runs if the event stream is noisy or mismatched.
Overview
Adds event-driven pending transaction polling by having
TransactionPollersubscribe toAccountActivityService:transactionUpdatedand trigger an immediate poll when an update matches the currentchainId, is a terminal status (confirmed/dropped/failed), is from the selected account, and corresponds to a currently pending tx hash.Refactors CAIP-2 chain-id conversion into a shared
caip2ToHexutility (used by bothTransactionPollerandIncomingTransactionHelper) and adds unit coverage for the new websocket trigger behavior and CAIP parsing; changelog is updated to announce the new polling mode.Written by Cursor Bugbot for commit bec1c47. This will update automatically on new commits. Configure here.